-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Azure AD Workload Identity support for Azure Scalers and Key Vault #2907
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, added a few remarks.
Would you mind opening a PR for the docs please?
Yeah, I have some minor changes left to do. Will get onto the docs after I am done with those. |
@tomkerkhove @JorTurFer @zroubalik Would be helpful if you can run all the azure* e2e tests. |
/run-e2e azure* |
@tomkerkhove I am not sure what changed exactly, but the Application Insight tests started failing recently (even on my dev cluster). Looking at the error, it seemed that the library was not able to send the metrics correctly with just the instrumentation key, and using the connection string resolves the issue. Could you add |
PR is open: #2934 |
/run-e2e azure* |
It's not enough, the yaml needs to be in main to be applied. Please undo the changes in the workflow yamls 🙏 |
@tomkerkhove @JorTurFer I want to raise a PR for the documentation here, but before that we would need to finalize upon and complete the helm changes. I can do the helm changes if someone guides me on how to go about them. |
Why does the docs have a pre-requisite on Helm? Normally that should not be the case. Our Helm charts are available in https://github.com/kedacore/charts where you can just open a PR to change the YAML specs (no need to bump versions) Let me know if you need help. |
Similar to pod identity, we need to mention the flags the user can use, right? |
I will go ahead with the helm changes as per the flags mentioned in this comment. Had a question regarding this. There are other changes in the main KEDA code, that also require helm changes (ex - TriggerAuth / ClusterTriggerAuth CRD changes done for Key Vault). Do I need to copy those changes over as well, right now, or do I just add my changes and the rest will be copied over during the release process? For context, I only need to change the service account template and values used for helm. |
You can already change v2.7 docs; there's no problem there as they only go live when we ship v2.7. Our new Helm chart version will only be available then as well. |
No, I was confused about the specific flags to add in docs as I was not sure if we had finalized them :) |
Helm Changes - kedacore/charts#263, kedacore/charts#264 |
Doc changes - kedacore/keda-docs#752 |
@tomkerkhove Could you once again run the e2e tests? Thanks. |
/run-e2e azure* Update: You can check the progres here |
No tests seem to be running here, weirdly. |
…ccount. Signed-off-by: Vighnesh Shenoy <[email protected]>
Signed-off-by: Vighnesh Shenoy <[email protected]>
Signed-off-by: Vighnesh Shenoy <[email protected]>
Signed-off-by: Vighnesh Shenoy <[email protected]>
|
/run-e2e azure* |
Signed-off-by: Vighnesh Shenoy <[email protected]>
@JorTurFer My guess is that the failures were due to the webhook components not being ready by the time keda is deployed. I have added some sleep in the setup section to try and resolve this issue. You can try running the test again. I would want for the test to at least pass twice before we can begin trusting them. |
/run-e2e azure* |
/run-e2e azure* |
/run-e2e azure* |
Personally, I don't have problems with keeping aad-wi there because there are e2e clusters and they are for that, but one question. Are both clusters ready (from Azure pov) or only this PR-e2e clusters is ready? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Thanks for this huge effort
@JorTurFer I am fine with either, keeping the components in the cluster or cleaning them up. Right now, the tests seem to be working with the clean-up and sleep included, so I guess we can keep them. The reason this test run failed was that both the normal service bus queue and workload identity tests ran together at the same time. If you want to be sure, you can run just the workload identity tests, regex - *workload-identity*. As for the permissions / grants, they have been done for both the pr-e2e and main-build clusters. But obviously they have not been run on the other cluster yet, so after merging we will need to check that they work over there as well. |
wow, that's true and I didn't notice! Please use another queue for this test to avoid fails in case of running both at the same time (like it has happened). I mean, changing the queue name should be enough for avoiding the collisions during tests, right? |
yes, if it's already the behavior, lets keep it |
Signed-off-by: Vighnesh Shenoy <[email protected]>
Yup, it just kind of slipped my mind that this would be a problem when the tests ran parallelly. Changed. Could you run the tests? (Hopefully last time, fingers crossed). |
/run-e2e azure-service-bus* |
/run-e2e azure* Update: You can check the progres here |
@JorTurFer @tomkerkhove Any more work to be done here? |
hey @v-shenoy |
Signed-off-by: Vighnesh Shenoy [email protected]
Support for Workload Identity as a pod identity provider.
Related PRs -
Helm Changes - kedacore/charts#263, kedacore/charts#264
Doc changes - kedacore/keda-docs#752
Checklist
Relates to #2487